9. SEARCH

Search in SharePoint knows no boundaries. It can surface physically living content in a SharePoint farm or external content outside of the farm.

With the advent of the service application model in SharePoint 2010, search became a first-class service that could scale beyond just one farm. You could publish a search service application from Farm A and consume it in Farm B. Search in SharePoint 2010 came in two flavors: enterprise search and FAST search. In enterprise search you had SharePoint Foundation search, SharePoint Server search, and Search server. FAST search, sold as a separate SKU, was added to the product when Microsoft acquired FAST. Each of the search products in SharePoint 2010 had their own focus (and cost) and demonstrated unique strengths and limitations.

With the current wave of Office 2013 products, Microsoft decided to unify search under one product and to extend it so that it can support the new programming model and architectural changes made to the platform. With the new unified product came many changes, which are highlighted next.

Search Schema

Search schema is a new name for search meta-data properties. Links to search schema, where you make meta-data property mapping, are now available in both site settings and site collection settings. That said, site owners no longer must be given access to or go to the search service application to work with meta-data properties.

Search Navigation

In SharePoint 2010, the only way to let users quickly jump between different search experiences was to create new scopes and new results pages, and bind them together. That way, new scopes would show up in the scope drop down in the top navigation, enabling users to perform a vertical search.

In SharePoint 2013, you can configure search navigation per site by browsing to Site Settings ⇒ Search Settings. This enables you to create different search experiences for users and includes them directly in the search box without using an additional scope drop down.

Figure 23 shows the new search navigation on the Search Settings page.

FIGURE 23

Search settings performed at the site level can be overridden at the site collection level by going to the Search Settings under the Site Collection Administration group. For example, you can configure all sites in a given site collection to use a search center and totally ignore the search navigation settings at the site levels.

Result Sources

Result source is the new name for scopes and federated locations in SharePoint 2010 with three major changes.

First, result sources can be accessed from the search service application and in Search Settings at each site.

Second, FAST is no longer an information source protocol; instead there are two new protocols: Exchange and Remote SharePoint. Select Exchange protocol for results from Exchange and Remote SharePoint for results from a search service application hosted in a separate farm.

Third, you can specify a filter that will be applied to your queries using new Query Transformation settings. This replaces Search Scope Rules in SharePoint 2010 and is handy when performing vertical search against something specific such as a Customers list or broad list such as a Sales statistics database. There is also a nice query builder that enables you to build your query transformations using a designer and sort and see the returned results in real time.

For example, using query transformation you can restrict the queries to information with a specific value for a managed property. The query transformation {searchTerms} author="Andy Au" returns only documents that have the user’s search terms (contained in the {searchTerms} token), and authored by "Andy Au". You can also prefix the queries. The query transformation Hockey{searchTerms} always adds the prefix Hockey and concatenates (AND) it with the user’s search terms.

The inclusion of result sources in SharePoint 2013 search provides a powerful mechanism to perform vertical searches against various information sources across your organization, such as sales data or knowledge-base articles.

Display Templates

As mentioned previously, SharePoint 2013 takes a different approach than SharePoint 2010 to customize the search results. Now, search-related web parts (that is, Search Result Web Part) heavily rely on display templates to control the appearance and behavior of results served from the index.

Display templates are snippets of HTML and JavaScript. There are many preconfigured display templates that ship with the product, but you can also create your own. Similar to customizing other templates in SharePoint, just copy an existing one that’s similar to what you want, and start from there. To do so, you can use any HTML editor you want.

Display templates can be found in Master Page Gallery ⇒ Display Templates ⇒ Search. As you can see, there are other types of display templates in the Master Page gallery used in other workloads such as WCM.

Result Types

Result types tie everything together. You use a result type to bind a result source or a type of search result to a display template that the search engine should use to render the search result.

Just like display templates, there are many out-of-the-box result types, and you can create your own. Each result type must have one or more conditions to compare search results against and an action that specifies what display template to use for the search result. For example, a custom result type named Knowledge Base specifies that if a search result is served from the result source KbRs, then use the display template KbDispTemplate.aspx to render the results.

Result types along with many other search configurations can be configured at the site collection level and at the site level.

Query Rules

A query rule is the last stop to modify and enhance the search experience before the core results are shown to the end user. A query rule has one or more conditions that must be met to make the rule fire. You can also define a query rule that fires for any search (which in turn means there is no rule).

A query rule is where you decide if you want to do one or more of the following:

Figure 24 illustrates a query rule that has been configured against the local SharePoint result source (used in Everything vertical) and is triggered when the user’s search term contains the word SharePoint.

FIGURE 24

After the rule triggers, it adds a promoted link (http://sharepoint.microsoft.com/iusesharepoint/landing.aspx) as a banner (it could also be a link) and then renders a result block that contains results from another result source pointing to an external website (http://blogs.devhorizon.com/reza). The rule puts everything above the core ranked results.

Conceptually, some of the things you can do by using query rules are similar to search keywords and best bets in SharePoint 2010. However, query rules are more powerful and highly dynamic, conditional, and customizable.

Continuous Crawl

SharePoint search plows through content using either full or incremental crawls. Full crawl focuses on almost everything about the content, whereas incremental crawls focus on picking up the changes in content or pushing the updated ACLs down to the affected items within the index. Because SharePoint 2013 relies heavily on search in some of the workloads such as WCM and Social, Microsoft introduced a new type of crawl: continuous crawl.

To provide maximum freshness, continuous crawls focus on smaller changes and use the change logs to pick up those changes faster and in more efficient ways. Continuous crawls overlap each other, which means one continuous crawl doesn’t hold up the other one in picking up the changes.

Two important tips about continuous crawls: First, they are only available for SharePoint content sources, where the choice is between continuous or incremental. Second, continuous crawl can’t be paused or stopped. Your only option is to disable it.

Putting It All Together

If you put together everything you have learned so far, you should realize how drastically search has been changed in SharePoint 2013. Figure 25 shows a high-level architectural overview of the new architecture side by side with the enterprise search in SharePoint 2010. You can see the difference.

FIGURE 25

To recap everything, here are the high-level steps you need to take to perform a vertical search in SharePoint 2013:

Query Languages

For developers, search has been always a great way to access content across site collections when the content freshness was not a deal breaker. In SharePoint 2013, continuous crawl resolves this issue to an extent. Another new change for developers is the query language they would use.

Let’s start with the bad news for many of you who know and love T-SQL style queries. SQL Query Language (SQL) using the FullTextSqlQuery class is no longer supported in SharePoint 2013. Start changing your SQL queries today if you plan to migrate to SharePoint 2013.

FAST Query Language (FQL) is still available, but developers are advised to use Keyword Query Language (KQL) and syntax to build their queries against a search engine. KQL has received some enhancements and is used almost everywhere you need to build a search query, such as those in query transformation and query rules. Table 3 includes a few examples of KQL queries:

TABLE 3: KQL Queries

Exporting and Importing Search Settings

If you have configured search or developed SharePoint applications that use search as the data access mechanism, you probably know that migrating your search configurations and settings across DEV, QA, and PROD environments was not an easy task. To target deployment scenarios, you had to write PowerShell scripts and XML configuration files to ensure your settings were applied consistently across your server farms.

In SharePoint 2013, you can export search settings or import them at the site level. This process handles query rules, result sources, and managed properties that you have created for a site, but you need to move the branding artifacts such as search master pages, display templates, and web parts. Any customization to the search result pages won’t be handled by the new search export and import feature.

You can export or important your search settings by browsing to Site Settings ⇒ Search ⇒ Configuration Export or Configuration Import.

Search-Driven Solutions

Because of the new improvements in search, you can build custom solutions that execute search queries using CSOM and REST. For example, the following REST query returns all the results containing the term “hockey”:

http://server/sites/sc/_api/search/query?querytext='hockey'

The following REST query returns all the results containing the term “hockey” sorted by last modified date and time, and in an ascending rank order:

http://server/site/_api/search/query?querytext='hockey'&sortlist='LastModifiedTime:descending,Rank:ascending'

The code snippet shown here demonstrates how to perform the same REST search call using CSOM within your apps:

ClientContext ctx = new ClientContext("http://Tailspintoys.com/sites/sc");
var query = new KeywordQuery(ctx, ctx.Site);
query.QueryText = "hockey";
query.ResultTypes = ResultType.RelevantResults;
query.Id = Guid.NewGuid();
var queries = new KeywordQuery[1];
queries[0] = query;
SearchExecutor searchExecutor = new SearchExecutor(ctx);
var rcc = searchExecutor.ExecuteQueries(queries);
ctx.ExecuteQuery();

No matter what approach you take to execute a KQL query in your apps or workflow, the results are always in the raw XML that you need to parse and extract what you want. You don’t get JSON objects in search queries.